Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-181.txt

Text File | 1992-12-31 | 46KB | 1,207 lines

C.S.M.P. Digest             Sat, 10 Oct 92       Volume 1 : Issue 181

Today's Topics:

    How do I mount a SCSI device?
    Hermes external in C
    Creating background tasks (HELP!).
    How to increase stack size ???



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Nick B Triantos)
Subject: How do I mount a SCSI device?
Date: 31 Aug 92 15:22:42 GMT
Organization: The University at Buffalo

Hi,

Forgive me if this is in the FAQ, but I couldn't find it.  I'd like to write a
program for myself that, when launched, will simply mount all SCSI devices it
finds in the chain.  I've looked in IM for a magic SCSIMount function, or
something reasonably close, and I can't find anything which I can understand.
Please post any suggestions you might have, or pointers to code which may help
me.

Thanks much,
- -Nick

- --
Nick Triantos    internet: [e-mail]
                 AOL:      Triantos
"Scientists tell us that the fastest animal on earth, with a top speed of
120 ft/sec, is a cow that has been dropped out of a helicopter." - Dave Barry

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 31 Aug 92 17:02:01 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]> [e-mail] (Nick B Triantos) writes:
>Hi,
>
>Forgive me if this is in the FAQ, but I couldn't find it.  I'd like to write a
>program for myself that, when launched, will simply mount all SCSI devices it
>finds in the chain.  I've looked in IM for a magic SCSIMount function, or
>something reasonably close, and I can't find anything which I can understand.
>Please post any suggestions you might have, or pointers to code which may help
>me.
>

Look at the low-level File Manager calls such as PBMountVol...I think this
is what you want.












- --
- -------------------------------------------------------------
joe zobkiw         [e-mail]        aol: aflzobkiw

+++++++++++++++++++++++++++

From: [e-mail] (Maarten Carels)
Date: 1 Sep 92 09:17:26 GMT
Organization: FWI, University of Amsterdam

[e-mail] (Joe Zobkiw) writes:
>In article <[e-mail]> [e-mail] (Nick B Triantos) writes:
>>Hi,
>>Forgive me if this is in the FAQ, but I couldn't find it.  I'd like to write a
>>program for myself that, when launched, will simply mount all SCSI devices it
>>finds in the chain.  I've looked in IM for a magic SCSIMount function, or
>>something reasonably close, and I can't find anything which I can understand.

>Look at the low-level File Manager calls such as PBMountVol...I think this
>is what you want.

Guess not. There is much more to do for SCSI devices. You have to:
- - determine it's there. Try to read block 0 from the device (you'll need it
  anyway). If you can't read the block, assume no device present.
- - using block 0, locate the driver on the disk, allocate memory in the system
  heap, read the driver, and jsr to it with some parameters in registers.
- - the driver should post a disk inserted event for any partition it wants
  to be mounted. Process all disk inserted events.

Documentation for all of this?
Inside Mac volume IV and V (SCSI manager, scsi disk layout)
some technotes
SCSI Development package (APDA, way out of date, but it some things are only
documented in comments in the example driver).

Are you sure you want to make such beastie?
SCSI hacking on macintoshes is fun, but it's not easy (I know, I made disk
drivers).

- --maarten
- --
In real life:    Maarten Carels
        Computer Science Department
        University of Amsterdam
email:        [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Bill Williams)
Date: 7 Sep 92 09:39:41 GMT
Organization: HoloNet (BBS: 510-704-1058)

>>mount all SCSI devices it finds in the chain.....



Do not write a mounting program unless you do it correctly. To do
 it correctly is too much work. I'll demonstrate:

Steps include

1: Finding all devices on the bus that are FIXED STORAGE, OPTICAL, and CD-ROM
while ignoring things like Voice Navigators and Scanners. Requires
knowledge of the SCSI Manager.

2: Unmounting all currently existing unmountable volumes supported by the
existing drivers for safety (plus you won't be able to unmount the system
volume or the current app volume)

3: Finding the first VALID HFS SCSI driver form the devices from the DDM
Driver Descriptor Map, in Block0 structure of disk (first block) Plus
reading just the first 512 bytes of the SCSI Block even if its logical
block size is larger than 512 bytes.

Then via block zero you can deduce which of several Partition map entries
in the PARTITION MAP partition is the desired driver. Then you need to
officially validate the checksum found in the partition map entry
describing the driver you are seeking via IM 5 if the partition map name
begins with 'MACI' in upper OR lower case

4: once found you need to load the driver into memory and check its memory
against its checksum for safety. Also you need to load it into a non
relocatable area of the system heap, and GUARANTEE THAT THE SYSTEM HEAP
 CAN AFFORD to accept a further loss of space (if not in System 7 with
expandable system 7 heaps). Size of driver is stored in partition map
entry but be careful not to multiply the logical block size (its units)
by the "ddSize" of the DDM since Apple structures are all internally
 stored using 512 byte logical blocks.

5: once the driver is ready and found, you need to jumpstart the driver as
if it was being called by the normal bootup processes of the Mac after
ILLEGALLY TAKING OVER THE CURRENT SCSI SLOT SPACE in the driver for that
device using Apples official current regular (non "Cousin It") guidlines:
(unit_Table_Ptr = (DCtlHandle *)UTableBase;
unit_Table_Ptr += 32 + device_ID;/* Point at SCSI ID direct slot */)


void Mount_SCSI_Drive(long scsi_Address, Ptr driver_Start)
{
  asm {
    movem.l    d0-d7/a0-a6,-(sp)
    suba.l     a0,a0
    moveq.l    #0,d7
    move.l     scsi_Address,d5
    bset.l     #31,d5    ;To indicate not being called at boot time
    move.l     driver_Start,a1
    jsr        (a1)
    movem.l    (sp)+,d0-d7/a0-a6
  } /* asm */

} /* pascal void Mount_SCSI_Device(INTEGER_32 scsi_Address... */


6: The Driver, not you,has the duty of cycling through partition entries
so Thats all there is. Thats it. They will mount.



Problems with ANY technique such as mounting like this include:
Having drivers ORPANED IN MEMORY! This is because no
SCSI drivers currently have to support a "Close" command and WILL BE
ORPAHANED. They may be may be doing evil background tasks, VBL tasks,
or have nasty shutdown manager calls installed. Taking over a SCSI Slot
space is naughty.


Conclusion: DO NOT WRITE a "SCSI Probe", nor use SCSI Probe. However the
steps just listed in this article are all properly done in the "SCSI
Director* Assistant 1.5.1" CDEV that has various names and was available
from 18 different companies including APS,Club Mac,VCP, etc etc.

PS "SCSI Probe 3.x" violates most rules and does things such as mounting
 OFFLINE devices that are OFFLINE and not Normal Device Queue Entries
(such as RAM Disks that are closed down with raw memory addresses in the
 entry, MS-DOS volumes, etc.  KaBOOM.

BWilliams

(If you need to speak to me use EMail since I never usually read
Mac oriented usenet stuff... but I may start)

+++++++++++++++++++++++++++

From: [e-mail] (Bill Williams)
Organization: HoloNet (BBS: 510-704-1058)
Date: Mon, 7 Sep 1992 08:32:26 GMT


---------------------------

From: [e-mail] (Mary Hicks)
Subject: Hermes external in C
Date: 29 Aug 92 21:45:18 GMT
Organization: FidoNet node 1:125/222.0 - Macademe/Emma, San Francisco CA

I would like to make an external for hermes, just as an example, but I
dont understand how. I read the Hermes Interface file, but I still need
help. I currently know how to program in C, but I cant make an external.



How would I compile this into an external.\]



main()

{

printf(" This is an example of a dumb external!");

}

- --------------------------------------------------

Well thats it. I also have the hermes headers fie in 'C', but how do I
compile the above code into an external? Please give step by step info.



thanks,

         Mary Hicks



- --
Mary Hicks - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!222.0!Mary.Hicks
INTERNET: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Peter Bierman)
Organization: Blue Moon BBS ((614) 868-998[024])
Date: Tue, 01 Sep 92 00:07:35 EDT

[e-mail] (Mary Hicks) writes:

> I would like to make an external for hermes, just as an example, but I
> dont understand how. I read the Hermes Interface file, but I still need
> help. I currently know how to program in C, but I cant make an external.

Well, first, get the HermHeaders in Pascal. The HEI file has some
examples, namely the phone external, that pretty much does what you asked.

The basic idea is that your external keeps a block in the heap with
variables. When you get called, you check a variable to see where you were
in your external, then you do a BIG case statement to get there. When you
finish one "stage" you update the stage variable to the next part of the
external to be called, and then go back to Hermes. Hermes should then do
some stuff, and call you again, and the cycle goes on.

It's pretty simple actually, just takes a little getting used to. Partly
because for a Mac programer, it's wierd to work in modes.


- ---
The opinions I express are rarely my own, because my own are far too
outragous to post here.

IntNet:[e-mail]    FutureNet: #33@#10
The Metropolis (614)-846-1911
- ---

+++++++++++++++++++++++++++

From: [e-mail] (Glen Stewart)
Date: 31 Aug 92 14:21:01 GMT
Organization: FidoNet node 1:2240/175 - The Associati, Grand Blanc MI

Mary -

You're pretty ambitious.  First I read you're looking for Basic source, now C
tips for Hermes...

I'm just completing a Think C project which is a very functional Hermes
external.  It's almost fully commented, and the program flow is pretty
understandable.  I'm no pro, but I've picked up that the standard printing
command is not acceptable to Hermes - it wants control of everything like
that.  So there are some special functions you can call that will take care of
this for you.

I'm struggling to fix a problem from the modification I made to the original
program, by Robert Duran Jr.  Once it is fixed (I'll be working on it this
afternoon, I hope), I'll put it online on my BBS and on the Hermes support
BBS.

The more basic functions are really easy to implement (simple textual
interaction), but anything calling the idle loop (hooks into the main
interface) are tricky and poorly documented.  I'm also trying to update the
HermesHeader.h to Hermes 2.0 status.  This update is also nearly complete -
trying to get a little help from Robert on this one.

Bye for now.


- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Glen Stewart - Internet: [e-mail]

---------------------------

From: [e-mail] (Ken Baer)
Subject: Creating background tasks (HELP!).
Date: 13 Aug 92 17:00:29 GMT
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.

OK, first of all, I do realize that the Mac OS does not yet support real
Multitasking (nor does MS Windows). But, I keep hearing about certain
applications or inits that allow programs to run in the background (like
the one that allows Think C to compile in the background).  What I want
to do is allow our 3D rendering software to render in the background to
the user can use the modeller etc. while rendering.  Could someone either
post, or point me to some documented code to set this up?  What are the
limits and conditions to this?  We are already doing this under Windows,
so I imagine a similar process should be possible on the Mac.

Any and all related information will be greatly appreciated.

    -Ken Baer.
    [e-mail]
- --
    //    -Ken Baer.  Programmer/Animator, Hash Enterprises
  \X/     Usenet: [e-mail]  /  Office: [phone]
          "Hey, I think a glacier just passed us!" - Andy from Joyride

+++++++++++++++++++++++++++

From: [e-mail] (Kent Borg)
Date: 14 Aug 92 00:05:35 GMT
Organization: Camex Inc., Boston MA

In article <[e-mail]> [e-mail] (Ken Baer) writes:
>OK, first of all, I do realize that the Mac OS does not yet support real
>Multitasking (nor does MS Windows).

Careful, thousands of people are cringing right now over the flame war
you might have just touched off.  (Some people are so irresponsible.)

>But, I keep hearing about certain applications or inits that allow
>programs to run in the background (like the one that allows Think C
>to compile in the background).

It is pretty easy for an application to do.  In fact, it is so easy
that INITs have been known to convince certain applications to do it.
(To be honest, I am pretty sure Think C has always allowed some
background processing, it just kept the user tied up while this went
on.)

>What I want to do is allow our 3D rendering software to render in the
>background to the user can use the modeller etc. while rendering.
>Could someone either post, or point me to some documented code to set
>this up?

Look in Inside Macintosh Volume VI or the new "Processes" volume of
Inside Macintosh for details, but in general, there are two things to
do:

1) When your code gets CPU time (you will know this because it is
executing) do your thing.

2) When the user decides to say something to your running code--for
example canceling the rendering he mistakenly started--notice the
"Stop" menu choice, or "Cancel" button, or command-period keystroke,
and act on it (by stopping in this case).

Because this is a user-oriented machine which is valuable precisely
for its user interface, be very responsive about noticing that the
user is talking to you.  Don't make the user pound on the keyboard.
To notice that the user is talking, call GetNextEvent(), and act on
anything you hear.  (Or call WaitNextEvent() if you are just sitting
around waiting for something to happen.)

Oh, and don't do anyThink stupid like putting up a traditional modal dialog
box.  It will prevent the user from switching to another layer.  Use a
regular window or a newer movable modal dialog instead.

Simple.  You are done.  You have written a program which is responsive
to the user and it is happily multitasking.

Okay, this does mean that inside your tight loops you need to notice
the passage of time and occasionally check for user input.  (Do this
several times a second--and possibly be clever and calibrate this at
runtime based on how fast my Mac can run your loop.)  But what do you
expect of an 8-plus-year-old architecture which started out in 128K of
unprotected RAM??  Don't get greedy.

The secret: Everytime you call GetNextEvent() or WaitNextEvent() the
system potentially offers execute time to other applications.
Everytime the other applications call one of those routines you
potentially get execute time.  Coopertive multitasking does require
cooperation but it makes for a very user-responsive system when folks
do cooperate.  It is what Modern True Real Time Multitasking Operating
Systems very often do--honest.


Make Sense?  If not, say so and there will be lots of helpful advice
coming your way--but PLEASE avoid fighting words like "Real
Multitasking" in future postings.


- --
Kent Borg                                   [e-mail] or [e-mail]
                                            H:[phone]  W:[phone]
As always, things look better when some costs are left out.
                              -Economist 3-28-92 p. 94

+++++++++++++++++++++++++++

From: [e-mail] (Chuck McMath)
Date: 14 Aug 92 12:32:58 GMT
Organization: MSD

In article <[e-mail]>,
[e-mail] (Ken Baer) wrote:
>
> OK, first of all, I do realize that the Mac OS does not yet support real
> Multitasking (nor does MS Windows). But, I keep hearing about certain
> applications or inits that allow programs to run in the background (like
> the one that allows Think C to compile in the background).  What I want
> to do is allow our 3D rendering software to render in the background to
> the user can use the modeller etc. while rendering.  Could someone either
> post, or point me to some documented code to set this up?  What are the
> limits and conditions to this?  We are already doing this under Windows,
> so I imagine a similar process should be possible on the Mac.
>
> Any and all related information will be greatly appreciated.

        Well, what you're really seeing is applications that can do tasks in
the background.  When the front application doesn't have pending events and
it calls WaitNextEvent background applications get time - that is, if the
frontmost application is well-behaved (please, gurus, correct me if I
misspeak!)

What you want to to is bone up (i.e., read Inside Mac) on the Event Manager
(maybe?) and see how applications that are not in the foreground get time.
Then you need to structure your rendering task so it can be done in small
chunks, because it would not be polite for a background task to grab the
computer and not let go (cf PrintMonitor!).  Once you set up your renderer
this way, it needs to be on the lookout for those events that apps get when
they're in the background, and do some rendering then.  It's easy to talk
about, but, I believe, difficult to achieve in practice!


chuck

|- chuck mcmath - [e-mail] - MSD, Inc. ------------|
|- National Library of Medicine - National Institutes of Health --|
|- Bethesda, MD 20894 -  !aixelsyd evah uoy siht daer nac uoy fI -|
|- "Hey batter, hey batter, hey batter, swing" - Anon. -----------|

+++++++++++++++++++++++++++

From: [e-mail] (Jason Philip Stevens)
Date: 14 Aug 1992 15:21:17 GMT
Organization: Baylor College of Medicine, Houston, Tx


In article <[e-mail]>, [e-mail] (Kent Borg) writes:
|> In article <[e-mail]> [e-mail] (Ken Baer) writes:

|> >What I want to do is allow our 3D rendering software to render in the
|> >background to the user can use the modeller etc. while rendering.
|> >Could someone either post, or point me to some documented code to set
|> >this up?
|>
|> Look in Inside Macintosh Volume VI or the new "Processes" volume of
|> Inside Macintosh for details, but in general, there are two things to
|> do:
|>
|> 1) When your code gets CPU time (you will know this because it is
|> executing) do your thing.
|>
|> 2) When the user decides to say something to your running code--for
|> example canceling the rendering he mistakenly started--notice the
|> "Stop" menu choice, or "Cancel" button, or command-period keystroke,
|> and act on it (by stopping in this case).

Another option that may be more in line with what you really want to do
is use threads.  The new Threads package from apple allows programs to
have multiple threads of execution.  In your case, a single program (not
seperate processes, as described above) could well shunt off all of the
compute intensive rendering into a new thread, that would chug along while
the user was free to interact with the rest of the program (which resides
in its own thread).

- -jps

- --
Jason Stevens            Internet:  [e-mail]
Network User Services        Voice:  [phone]
Baylor College of Medicine    Opinions expressed are mine alone.


+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 24 Aug 92 00:50:37 GMT

In <[e-mail]> [e-mail] (Kent Borg) writes:

>In article <[e-mail]> [e-mail] (Ken Baer) writes:

>>What I want to do is allow our 3D rendering software to render in the
>>background to the user can use the modeller etc. while rendering.
>>Could someone either post, or point me to some documented code to set
>>this up?

>1) When your code gets CPU time (you will know this because it is
>executing) do your thing.

>2) When the user decides to say something to your running code--for
>example canceling the rendering he mistakenly started--notice the
>"Stop" menu choice, or "Cancel" button, or command-period keystroke,
>and act on it (by stopping in this case).

3) Set the "accept background null events" in your size resource or you'll
wait a really long time for your code to finish if you switch it to the
background...  I forget to do this way too often.

>Because this is a user-oriented machine which is valuable precisely
>for its user interface, be very responsive about noticing that the
>user is talking to you.  Don't make the user pound on the keyboard.

Er, technically speaking the user cannot interact with your program
while it is in the background.  He/she/it must switch it to the
foreground to cancel the rendering.  I assume your renderer already
allows cancel, so no changes here.  I believe the only two events you
get while you are backgrounding are nullEvt and updateEvt and an
OS activate event when you get switched back forward.  (I think...)

Pass very small values to the sleepTime parameter in WaitNextEvent
(don't use GetNextEvent unless you HAVE to), and when you get time,
take a tick or two and get a few more calculations again.  Then call
WaitNextEvent so that other processes can get their fair time.  You
can use the following loop so that you can get the processor for a
fair amount of time:

// Uncompiled C code from memory below -- use at own
// risk, but you get the idea.
long l; EventRecord e;
while( task not done ) {
    if( WaitNextEvent( everyEvent, &e, 0L, nil ) ) {
    HandleUpdateOrOSEvent();
    } else {
        l = Ticks + 2;
        do {
        SmallIncrementalPartOfYourTask()
    } while( Ticks < l );
    }
}

Note that if you want to be future compatible, use TickCount() instead
of the low memory global Ticks.  I use TickCount() because I figure that
if Ticks ever fails, it will be trivial to re-compile using TickCount().
However, none of the apps I've developed have been commercial (so far)
so I haven't had to worry about expensive upgrades.

This is how I've been doing it.  If anyone has any suggestions, please
do tell.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Kent Borg)
Date: 24 Aug 92 17:34:40 GMT
Organization: Camex Inc., Boston MA

In article <scott.714617437@mcl> [e-mail] (Scott Bronson) writes:
>(don't use GetNextEvent unless you HAVE to)

Quite right.  My posting was wrong.  I though that WaitNextEvent()
reduced to the same thing as GetNextEvent() when the wait was zero and
the rgn empty.  Wrong.  WaitNextEvent() also calls SystemTask() for
you--and possibly other differences I am still forgetting.  I knew
this and forgot it and got burned by it just last week.

Bottom line: Only use GetNextEvent() when WaitNextEvent() doesn't
exist (on old systems, for example).

- --
Kent Borg                                   [e-mail] or [e-mail]
                                            H:[phone]  W:[phone]
As always, things look better when some costs are left out.
                              -Economist 3-28-92 p. 94

+++++++++++++++++++++++++++

From: [e-mail] (Joshua Rabinowitz-Summer-91)
Date: 24 Aug 92 23:49:02 GMT
Organization: NASA/ARC Information Sciences Division

In article <[e-mail]> [e-mail] (Kent Borg) writes:
>In article <scott.714617437@mcl> [e-mail] (Scott Bronson) writes:
>>(don't use GetNextEvent unless you HAVE to)
>
>Quite right.  My posting was wrong.  I though that WaitNextEvent()
>reduced to the same thing as GetNextEvent() when the wait was zero and
>the rgn empty.  Wrong.  WaitNextEvent() also calls SystemTask() for
                          ^^^^^^^^^^^^^^^^^^

No.  WaitNextEvent() does NOT call systemTask() -- it has it's own
way of dealing with this type of action for you.  But it does not,
to the best of my knowledge, call SystemTask(), which should not be used
(does nothing?) under systems with WaitNextEvent().

>you--and possibly other differences I am still forgetting.  I knew
>this and forgot it and got burned by it just last week.

Not trying to flame.

>
>Bottom line: Only use GetNextEvent() when WaitNextEvent() doesn't
>exist (on old systems, for example).

YES.

>
>--
>Kent Borg                                   [e-mail] or [e-mail]
>                                            H:[phone]  W:[phone]
>As always, things look better when some costs are left out.
>                              -Economist 3-28-92 p. 94


- --
- ----------------------------------
#include <std/disclaimer.h>     Josh Rabinowitz, Mac TCL programmer
[e-mail]
"Send a salami to your boy in the army" - Katz's delicatessen, NYC

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Urlichs)
Date: 8 Sep 92 15:17:51 GMT
Organization: University of Karlsruhe, FRG

In comp.sys.mac.programmer, article <[e-mail]>,
  [e-mail] (Joshua Rabinowitz-Summer-91) writes:
> In article <[e-mail]> [e-mail] (Kent Borg) writes:
> >In article <scott.714617437@mcl> [e-mail] (Scott Bronson) writes:
> >>(don't use GetNextEvent unless you HAVE to)
> >
> >Quite right.  My posting was wrong.  I though that WaitNextEvent()
> >reduced to the same thing as GetNextEvent() when the wait was zero and
> >the rgn empty.  Wrong.  WaitNextEvent() also calls SystemTask() for
>                           ^^^^^^^^^^^^^^^^^^
>
> No.  WaitNextEvent() does NOT call systemTask() -- it has its own
> way of dealing with this type of action for you.  But it does not,
> to the best of my knowledge, call SystemTask(), which should not be used
> (does nothing?) under systems with WaitNextEvent().

WaitNextEvent calls GetNextEvent when the wait is zero and the region empty.
GetNextEvent calls SystemTask internally.
(This is under System 7.0.1. Set a BReak on WaitNextEvent, Go, set a BReak
 on SystemTask, Go, StackCrawl, examine code at calling points.
 Clear breakpoints, Go.  All this is Macsbug; your debugger may vary. :-)
All three routines are reimplemented by System 7.

Given this, calling SystemTask is superfluous but definitely harmless.

- --
"For that matter, compare your pocket computer with the massive jobs of
a thousand years ago.  Why not, then, the last step of doing away with
computers altogether?"
        -- Jehan Shuman
- --
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

---------------------------

From: [e-mail]
Subject: How to increase stack size ???
Organization: University of Western Ont, London
Date: Tue, 1 Sep 1992 18:56:11 GMT


I am working on a port of Gunplot 3.2 to the Mac. So far I have most
of the basics working (only a few bugs left) ... however, I keep
running out of stack space. I did some reading and found out that the
Mac only provides 8k of stack space and that it can be changed by doing
something like (in VERY rough C pseudo-code)

        THz newapplimit;

        newapplimit = 300*1024;    /* give app 300k */
        SetApplLimit(ApplLimit()+newapplimit);
        MaxApplLimit();

Unfortunately, this does not work ...

Can anyone enlighten me? I would like to set up a fixed stack size of
32k (i.e. not dependent on the memory allotted by the user in the
applications info box). I am using Think C 5.02.

Thanks,
Todd Schneider

+++++++++++++++++++++++++++

From: [e-mail] (Duane A Murphy)
Date: 2 Sep 92 15:48:22 GMT
Organization: Novell, Inc. - Walnut Creek

In article <[e-mail]> [e-mail] writes:
>
>I am working on a port of Gunplot 3.2 to the Mac. So far I have most
>of the basics working (only a few bugs left) ... however, I keep
>running out of stack space. I did some reading and found out that the
>Mac only provides 8k of stack space and that it can be changed by doing
>something like (in VERY rough C pseudo-code)
>
>        THz newapplimit;
>
>        newapplimit = 300*1024;    /* give app 300k */
>        SetApplLimit(ApplLimit()+newapplimit);
>        MaxApplLimit();
>
>Unfortunately, this does not work ...
>
>Can anyone enlighten me? I would like to set up a fixed stack size of
>32k (i.e. not dependent on the memory allotted by the user in the
>applications info box). I am using Think C 5.02.
>
>Thanks,
>Todd Schneider

I also ran into a stack limitation problem.  Actually the stack is handled
differently on different machines.  It is not consistent.  "Small" machines
have an 8K stack.  "Large" machines have a 24K stack.  There is a low memory
global "DefltStack" that determines the stack size at startup.  Dont mess
with this, it affects everyone.

After a few days of trying to figure out how the stack space is managed;
that is what pointers in the heap kept track of the stack to detect a
stack heap collision, we came up with the following very simple solution.

#define STACK_MIN 0x8000L
pascal Ptr StackPtr(void) = {0x2e8f};    /* MOVE A7, (A7) */

int main(void)
{
    SetApplLimit(StackPtr() - STACK_MIN);
...

The StackPtr() function came from the net (thanks to whomever suggested
this).  The stack has no direct pointers to set its limits.  It is actuall
controlled by heap limit pointers, namely ApplLimit.  This moves ApplLimit
the where the current stack is at down the size of the stack that you
want.

Hope this helps,
...Duane Murphy
Novell, Walnut Creek

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 2 Sep 92 18:55:00 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Duane A Murphy) writes:
>In article <[e-mail]> [e-mail] writes:
>>...I keep running out of stack space.
>
>I also ran into a stack limitation problem.  Actually the stack is handled
>differently on different machines.  It is not consistent.  "Small" machines
>have an 8K stack.  "Large" machines have a 24K stack.  There is a low memory
>global "DefltStack" that determines the stack size at startup.  Dont mess
>with this, it affects everyone.

Color QuickDraw machines do have a 24K default stack.  Be aware that
the Process Manager always increases the partition size by (default
stack - 8K) when launching applications, so the extra 16K stack space
on Color QuickDraw machines does not reduce the heap size under what
would be available on a 68000 machine (but the app's partition is
16K larger than the partition size set by the programmer.)

>pascal Ptr StackPtr(void) = {0x2e8f};    /* MOVE A7, (A7) */
>...
>    SetApplLimit(StackPtr() - STACK_MIN);

This is a bit more 680x0 dependent than source code should be these
days.  Here's a function which uses documented calls to increase the
stack size.

  // Increase the space allocated for the application stack
  //
  // Warning: SetApplLimit always sets the stack to at least as large as the
  //    default stack for the machine (8K on machines with original QuickDraw,
  //    24K on machines with Color QuickDraw) so the application partition
  //    must be large enough to accomodate an appropriate stack and heap

  OSErr IncreaseApplicationStack(Size incrementSize)
  {
    OSErr retCode;

    // increase the stack size by lowering the heap limit
    SetApplLimit((Ptr) ((unsigned long) GetApplLimit() - incrementSize));
    retCode = MemError();
    if (retCode == noErr) MaxApplZone();

    return retCode;
  }

Do heed the warning given in the comment.  All stack allocation beyond
the default must be compensated for by increasing the partition size in
the SIZE -1 resource.

This is particularly an issue for faceless background apps, which have
a default stack size of only 2K.  SetApplLimit will grow an FBA's stack
to at least 24K on Color QuickDraw machines, so the partition size
should be larger than that.


Grobbins               [e-mail]

Usual disclaimers apply.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 2 Sep 92 00:31:07 GMT
Organization: Apple

In article <[e-mail]>, [e-mail] wrote:
>
>
> I am working on a port of Gunplot 3.2 to the Mac. So far I have most
> of the basics working (only a few bugs left) ... however, I keep
> running out of stack space. I did some reading and found out that the
> Mac only provides 8k of stack space and that it can be changed by doing
> something like (in VERY rough C pseudo-code)

MacII ROMs: 24k
Old Macs (Plus, SEs): 8k
Color QuickDraw systems: 24k
MacApp applications (24k by default).

>
>         THz newapplimit;
>
>         newapplimit = 300*1024;    /* give app 300k */
>         SetApplLimit(ApplLimit()+newapplimit);
>         MaxApplLimit();
>
> Unfortunately, this does not work ...

In what way, collision of stack and heap (more memory required then)?
Other problems?

Kent Sandvik/DTS

+++++++++++++++++++++++++++

From: [e-mail] (John Wallace)
Date: 2 Sep 92 20:23:29 GMT
Organization: TRW Sensor Data Processing Center, Redondo Beach, CA

In article <[e-mail]> [e-mail] (Duane A Murphy) writes:
>In article <[e-mail]> [e-mail] writes:
>>
>>I keep running out of stack space.
>>Todd Schneider
>
>I also ran into a stack limitation problem.  Actually the stack is handled
>differently on different machines.  It is not consistent.  "Small" machines
>have an 8K stack.  "Large" machines have a 24K stack.
>
>#define STACK_MIN 0x8000L
>pascal Ptr StackPtr(void) = {0x2e8f};    /* MOVE A7, (A7) */
>
>int main(void)
>{
>    SetApplLimit(StackPtr() - STACK_MIN);
>...
>
>
>Hope this helps,
>...Duane Murphy
>Novell, Walnut Creek
>

You may want to change this to:

if (StackSpace() < STACK_MIN)
    SetApplLimit(StackPtr() - (STACK_MIN - StackSpace()))

This will make sure that you don't waste too much memory on "Large"
machines.  (StackSpace is a standard Toolbox trap.)  Also, some
development envrionments automatically call SetApplLimit as part of
the normal application startup.  For example, THINK Pascal calls
SetApplLimit to allocate the amount of stack space you specified under
your Run Options.  Check your development environment documentation to
see if it provides this kind of support.

Cheers!
John
- ---------------------------------------------------------------------
John Wallace                     [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Marshall Clow)
Date: 2 Sep 92 21:40:32 GMT
Organization: Hewlett Packard San Diego Printer Division

In article <[e-mail]>, [e-mail] (Grobbins) wrote:
> [ lots of good advice deleted ]
>
> This is particularly an issue for faceless background apps, which have
> a default stack size of only 2K.  SetApplLimit will grow an FBA's stack
> to at least 24K on Color QuickDraw machines, so the partition size
> should be larger than that.
>

In writing a FBA we tracked down several cases where inits (oops,
extensions) would patch a trap, and then when the trap was called, would
casually throw a few Str255s on the stack, or maybe a 1K buffer.

Needless to say, when an OS call used over 1K of stack space and you only
have a 2K stack, you are headed for problems.


Marshall Clow
San Diego Printer Division      Hewlett Packard
Internet: [e-mail]   AppleLink: HP.Marshall    AOL: MClow

+++++++++++++++++++++++++++

From: [e-mail] (Duane A Murphy)
Date: 3 Sep 92 18:08:37 GMT
Organization: Novell, Inc. - Walnut Creek

In article <[e-mail]> [e-mail] (Grobbins) writes:
>
>  // Increase the space allocated for the application stack
>  //
>  // Warning: SetApplLimit always sets the stack to at least as large as the
>  //    default stack for the machine (8K on machines with original QuickDraw,
>  //    24K on machines with Color QuickDraw) so the application partition
>  //    must be large enough to accomodate an appropriate stack and heap
>
>  OSErr IncreaseApplicationStack(Size incrementSize)
>  {
>    OSErr retCode;
>
>    // increase the stack size by lowering the heap limit
>    SetApplLimit((Ptr) ((unsigned long) GetApplLimit() - incrementSize));
>    retCode = MemError();
>    if (retCode == noErr) MaxApplZone();
>
>    return retCode;
>  }
>
>Do heed the warning given in the comment.  All stack allocation beyond
>the default must be compensated for by increasing the partition size in
>the SIZE -1 resource.
>

Be forwarned to test this on many machines (namely an SE or other 68000
based machine).  I believe I tried this; it may have even been one of
my first attempts.  I think this works but is it what is desired?

This increases the stack size by an amount.  It does not _SET_ the stack
size.  I needed (as I believe the original author did) to set the
stack size to a particular size.

...Duane

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 4 Sep 92 03:25:10 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Duane A Murphy) writes:
>This increases the stack size by an amount.  It does not _SET_ the stack
>size.  I needed (as I believe the original author did) to set the
>stack size to a particular size.

The original poster wanted to be guaranteed at least a 32K stack
regardless of the application's partition size setting.

It is not a good idea to set the stack to a specific size (although it
can be done by setting ApplLimit to CurStackBase minus the desired size)
because the System may decide to make demands of your stack beyond
the normal default.  It can do so safely by just upping the default
stack and partition sizes when launching.

This happened with the introduction of Color QuickDraw.  Additional
stack space was necessary for safe QuickDraw use, so the default stack
size was upped to 24K and the partition size of each application was
increased upon launch to accomodate the larger stack.

Any application which sets a specific stack size after launching
defeats the ability of System software to increase the stack.
At the time the program is written, 16K may be plenty large for the
stack, but that may not be true for the same program under some
future version of System software.

For this reason, DTS has for some time advocated that the stack be
increased when necessary (by lowering ApplLimit), but not fixed to
a specific size.

Grobbins           [e-mail]

Usual disclaimers apply.


+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 4 Sep 92 14:03:50 GMT
Organization: Symantec Corp.

>>>>> On Wed, 2 Sep 92 20:23:29 GMT, [e-mail] (John Wallace) said:

 > if (StackSpace() < STACK_MIN)
 >     SetApplLimit(StackPtr() - (STACK_MIN - StackSpace()))

 > This will make sure that you don't waste too much memory on "Large"
 > machines.  (StackSpace is a standard Toolbox trap.)

This is the best solution, but... On 68000 machines, the trap
StackSpace() returns garbage unless you've already called
MaxApplZone() (in which case the call to SetApplLimit will fail). I'm
not sure, but this may have been fixed in System 7.

In any event, I would recommend using the low memory global DefltStack
instead. In THINK C, you can just write:

    SetApplLimit(GetApplLimit() - (STACK_NEEDED - DefltStack));

In MPW C, you'd use:

    SetApplLimit(GetApplLimit() - (STACK_NEEDED - *((long *)DefltStack)));

In Pascal, you'd use:

    SetApplLimit(GetApplLimit - (STACK_NEEDED - LongPtr(DefltStack)^));

Is this in the FAQ?

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Duane A Murphy)
Date: 4 Sep 92 16:00:59 GMT
Organization: Novell, Inc. - Walnut Creek

In article <[e-mail]> [e-mail] (Phil Shapiro) writes:
>>>>>> On Wed, 2 Sep 92 20:23:29 GMT, [e-mail] (John Wallace) said:
>
> > if (StackSpace() < STACK_MIN)
> >     SetApplLimit(StackPtr() - (STACK_MIN - StackSpace()))
>
> > This will make sure that you don't waste too much memory on "Large"
> > machines.  (StackSpace is a standard Toolbox trap.)
>
>This is the best solution, but... On 68000 machines, the trap
>StackSpace() returns garbage unless you've already called
>MaxApplZone() (in which case the call to SetApplLimit will fail). I'm
>not sure, but this may have been fixed in System 7.
>
>In any event, I would recommend using the low memory global DefltStack
>instead. In THINK C, you can just write:
>
>    SetApplLimit(GetApplLimit() - (STACK_NEEDED - DefltStack));
...

Thank you for jogging my memory.  This is the problem that I ran into.
Once MaxApplZone is called adjusting the stack space larger will
cross into the heap space simulating a stack heap collision.  That is
why it was necassary to adjust the stack size at the start as opposed
to dynamically at run time. (I think this sounds rights).

How can one adjust the stack size dynamically (as recommended by DTS)
when it simulates moving the stack into the heap?

No it is not fixed on System 7.  In fact StackSpace() works differently on
different models with the _SAME_ system!  This was very confusing.

...Duane

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 5 Sep 92 21:03:26 GMT
Organization: Apple

In article <[e-mail]>, [e-mail]
(Marshall Clow) wrote:
> In article <[e-mail]>, [e-mail] (Grobbins) wrote:
> > [ lots of good advice deleted ]
> >
> > This is particularly an issue for faceless background apps, which have
> > a default stack size of only 2K.  SetApplLimit will grow an FBA's stack
> > to at least 24K on Color QuickDraw machines, so the partition size
> > should be larger than that.
> >
>
> In writing a FBA we tracked down several cases where inits (oops,
> extensions) would patch a trap, and then when the trap was called, would
> casually throw a few Str255s on the stack, or maybe a 1K buffer.
>
> Needless to say, when an OS call used over 1K of stack space and you only
> have a 2K stack, you are headed for problems.

Another hint, check out what MoveHHi is doing with the stack. I'm not
telling it :-).

Kent Sandvik/DTS

+++++++++++++++++++++++++++

From: [e-mail] (Chuck Pliske)
Date: 9 Sep 92 05:24:09 GMT
Organization: University of Washington

In article <[e-mail]> Duane A Murphy,
[e-mail] writes:
>>In any event, I would recommend using the low memory global DefltStack

I wrote an extension "Stack6000", useful for the 68000 machines because
Apple sets the default stack to about $4800 in the Plus, SE and PB100,
and $6000 on the other machines.  I simply set DefltStack to $6000 (if
needed) and exit.  Subsequent programs using the default all get the new
value.  So far, it has worked fine.  (Available on Sumex)

Chuck

---------------------------

End of C.S.M.P. Digest
**********************